Should this also be in a 0.9.x version? I guess not, seeing the changelogs.
I would say 1.85 is a bit too recent for a patch update.

Are we planning for a 0.10 release of rand_core? I understood it we want to release rand 0.10 with rand_core 0.9 and not have rand_core 0.10 for now.

Should this also be in a 0.9.x version? I guess not, seeing the changelogs.

No, this is for v0.10. I wanted to make a pre-release using chacha20, but we may not be ready to do that yet.

Are we planning for a 0.10 release of rand_core? I understood it we want to release rand 0.10 with rand_core 0.9 and not have rand_core 0.10 for now.

Good point.

So should we keep the old MSRV for rand_core (and maybe some of the other crates)? I guess then we should... which means that we need two CI paths for MSRV tests.

So should we keep the old MSRV for rand_core (and maybe some of the other crates)?

Probably, yes. It would allow us to explicitly relax the MSRV policy to allow MSRV bumps in patch releases because of the MSRV-aware resolver. It may be even worth to release getrandom v0.4, not only to relax MSRV policy, but also to remove the built-in Web WASM support in favor of the custom fallback approach.

@newpavlov how does keeping some crates on rustc 1.63 help us relax the MSRV policy? The new resolver isn't available until 1.84.

No comment on getrandom here except that the plan is to not make a breaking release of rand_core for now, hence we'd have to evaluate whether upgrading to getrandom v0.4 would be a breaking change for users of rand_core.

Sorry, I misread your comment. I thought you suggested to cut new releases of rand_core with MSRV bumped to 1.85.

Looks like we can't test rand_core with rustc 1.63 once other crates are updated:

$ cargo +1.63 test --all-features
error: failed to parse manifest at `/home/dhardy/projects/rand/rand/Cargo.toml`

Caused by:
  failed to parse the `edition` key

Caused by:
  this version of Cargo is older than the `2024` edition, and only supports `2015`, `2018`, and `2021` editions.

The rust-version update isn't an issue but the edition update is.

Solutions:

1. Don't test the rand_core MSRV. Not ideal but might be the least-worst option.
2. Re-organise so that rand is in a sub-directory and the top-level Cargo.toml only lists workspace members. Untested. Undesirable because of conflicts and overhead when tracking other changes.

I removed all changes to rand_core (only code change was a Clippy suggestion + reformat).

rand_core is tested only on the same MSRV as every other crate due to the issue noted above.

Solutions:

You forgot about cutting new breaking release of rand_core with MSRV 1.85. :)

As a practical solution we also could modify the MSRV job to remove the crate from the workspace by executing rm Cargo.toml && cd rand_core/.

You forgot about cutting new breaking release of rand_core with MSRV 1.85. :)

It would be simpler.

Motivation to persist with rand_core v0.9: upgrades to rand v0.10 will be easier for people who can't just upgrade everything at once. I don't think this affects a lot of people, but rand_core_compat exists for a reason.

Motivation not to update the MSRV for the next rand_core point release: while I can conceive of a scenario where this might be an issue, it's hard to imagine why someone would need to use the latest rand_core version with an old rustc version. It seems unlikely we'll need a new rand_core point release anyway.

Overall I'm tempted to leave rand_core unchanged: no special 1.63 test, no upgrade to Edition 2024 or the latest MSRV.